第6章 シンプルな設計
シンプリシティ
ケント・ベックの4行
『Clean Code』にも（TODO）
シンプルは「簡単」という意味ではない。シンプルとは「もつれていない、絡み合っていない」という意味である。(Kindle版 p.262)
もつれの例：高レベルの方針が低レベルの詳細と結合
シンプルな設計とは、高レベルの方針が低レベルの詳細を知らない設計である。(Kindle版 p.262)
インターフェースの利用（HighLevelInterface 図6-1）
フックを仕込んでいた（1980年代〜1990年代）
当時は変更しづらかったから
技術的飛躍に後押しされ、YAGNIの規律やケント・ベックによるシンプルな設計の4つの原則が実用的になった (Kindle版 p.264)
YAGNI
なくても許容できるなら作るべきでない
フックを使わないことがほとんどになった
計算機パワーにより、包括的なテストが数秒で実行できる
テストでカバーする
ルーツ
ケント・ベックの『エクストリームプログラミング』（おそらく初版）に言及
2011年版（TODO ソース）
Uncle Bob版も紹介
テストカバレッジ
cover＝網羅する＝100%
漸近させる
テスト可能なコードは分離されたコードである。(Kindle版 p.269)
テストの作成は設計活動
残り3つのルールはリファクタリングに関する
リファクタリングには信頼できるテストスイートが必要
表現の最大化
プログラミング初期と比べて、現在の「言語は表現力が非常に豊か」
『Clean Code』でも言及しているらしい
アプリケーションに内在する抽象概念を表現する
低レベルの詳細から高レベルの方針を分離することが基本
本番コードの表現力を高める一方で、テストは本番コードが使用される文脈を伝える
隔離・分離されているテストは、本番コードがどのように使用されるのかを表している。(Kindle版 p.274)
重複の最小化
IMO：ソースコードエディタ登場前はコピー&ペーストがなかったという話、面白い
本物の重複は排除する
偶然の重複は残す
理解（IMO）：現状たまたま重複している（要件が変われば片方だけ変わり、重複していない状態になりうる）
テストによるカバーと表現力が先。その後の3番めに重複の排除
サイズの最小化
シンプルな要素は小さい。(Kindle版 p.277)
ケント・ベックの主張：4つのルールを守れば、その他すべての設計原則が満たされる
IMO：興味深い
Uncle BobはSOLID原則を満たすかは不明と言っている
例えばSOLID原則を学ぶことで、シンプルな設計を作れるようになるはず